state management

2019-07-16

I managed to get to the point where stickies with no text show up.

Stickies without text are now displayed.

The text portion is commented out.

The path is commented out now.

The group is commenting out now too.

The canvas resize event is also commented out and fixed size.

We'll revert these areas one by one so that the display is restored to its original state.

Then first move the parallel shift and zoom, then move the sticky by dragging it.

2019-08-02

Text displaydone

base canvas and overlay canvas each have a PaperScope

I named them basePaper and overlayPaper.

Delete app.paper

They use it all over the place in many places.

Tool is also hanging on app.paper

Comment out once

Can now zoom in and out (dies trying to set state when zooming is complete)

Commented out thinking that it may not be necessary to update the status

Zooming is now possible.

Achieve parallel movement

Open MANUAL for viewing.

commit id: f182638

---

A collection of things written in pRegroup:.

Priority is given to improving the state management system rather than speeding up small steps.

Selection and highlighting status management

Shouldn't DefaultTool's highlight/deselect be integrated with Selection's?

All state updates are in the undo list, which is not appropriate

---

Organize your understanding of state management renewal

Essentially, this app is "an app that renders to HTML5 Canvas

Using Paper.js instead of drawing directly in Canvas (for rounding off hit judgments, etc.)

When the React-like state is updated, all Paper#Item is destroyed and regenerated.

That implementation works fine on Chrome on PC.

Uncomfortable flashing on "stickies with images" in Safari on iPad, Chrome, and Safari on PC, regardless of the number of stickies.

Probably only Chrome on PC, caching images in a layer (=browser) below Paper.js

Paper#item must not be discarded in order to work comfortably on iPad

That means that when the React-like state is updated, the Paper.js layer needs to deal with it by modifying or moving existing objects

This is almost the same processing that React does for the DOM, and it is handled by the Reconciler

You need to implement your own Reconciler or use an existing implementation. I don't want to implement it, so use react-paper-bindings

In addition, the entire state is currently subject to UNDO, but UNDO will be changed to push snapshots as needed.

-----

However, the final output is a list of elements in paper.js, so we can't use the DOM manipulation methods, so we need to figure out how to do that.

Observation of how react-paper-binding is implemented

From componentDidUpdate, we call PaperRenderer.updateContainer, and this PaperRenderer is a Reconciler

The point that an object must have a unique ID is called Key in React language.

When there is an update to a component that has child elements in the

Looks good because it uses react-paper-binding

And as for which is better, I can't make a decision.

This one was last updated more recently.

I think react-paper-binding has more contributors.

state management

I'm sure the ideal of "100 image stickies and no flickering" can be achieved if you work on the deeper aspects of the design.

This one, not so easy when it comes to "keeping UNDO functioning."

That said, I'm not sure I'd want to throw away the UNDO feature...

Organizing the Issue

When I looked into the UNDO/REDO mechanism that made sense with React's state management, I found that the two implementations I referred to were both "redrawing everything when the state is updated," which made me wonder at the time if that was a good idea. Wouldn't that cause performance problems? Shouldn't it be managed in terms of revision differences? Then I started to think

I'm a bit bewildered, but too early optimization is the root of all evil, so I'll start by creating an implementation that retains the entire state history.

So, we made the decision to use the new system. But, surprisingly, we didn't have any performance problems even when we put out 100 sticky notes and moved them around.

So, we've come this far and finally had a problem with the "100 image stickies on the iPad" requirement.

Even with a single image, the behavior is that "the image is drawn with a delay of 0.5 to 1 second on the iPad," so to solve this problem, the implementation must be such that objects that have already been drawn are used as much as possible.

Do we need to treat Paper.js's tree of objects like React's virtual DOM?

Is this how you would approach it?

I want to be able to co-edit.

I still want to move stickies around with my finger on the iPad.

As for adding stickies, I want to use the keyboard, so I want to do it on my PC.

Because I opened it in two places in edit mode, I made the mistake of editing one and overwriting the other. w

After all, even if it is used by one person, collaborative editing should be possible (conclusion).

The reason why co-editing is turned off now is that "if one editor is in the middle of dragging and the other editor's edit arrives and the object is re-created, it will die because it cannot find the object to be dragged when the drag is complete". So, in the end, it should be a mechanism that Paper#Item has a reference to a state object (StateItem) on React, and all StateItem have a unique ID, and when the drag is completed, the object with that ID is searched for in the scene tree and updated.

---